持续更新中……
System Design
Basic Steps
- Clarify and agree on the scope of the system
- User cases
- Who is going to use it
- How are they going to use it
- Constraints
- traffic
- high availability
- …
- User cases
- High level architecture design (Abstract design)
- Sketch the important components and connections between them, but don’t go into some details
- service layer
- data storage layer
- key components, eg: caching, load balance, database cluster
- Sketch the important components and connections between them, but don’t go into some details
- Component Design
- interface
- OOD for functionalities
- Map scenario to module
- Understanding Bottlenecks
- Scaling
SNG后台技术分享
- 定义可用性
- 考虑成本及损失的用户价值，2个9到4个9，3.65天到52min
- 估算
- 熟悉常见性能指标，通过估算而非测试得知系统能力
设计优化（面向海量用户）
把业务指标抽象为技术细节，10亿访问量/天 => 高峰并发访问量2~3w/秒 => 负载均衡到每台服务器
- 代码级优化
- 熟悉算法，数据结构，外部技术依赖如网络协议
- 主动寻找优化空间，如内存开销，瓶颈，漏洞
- 系统设计级优化 （以存储海量小文件为例）
- 技术要点
- 技术可行性，可扩展性，高并发/低成本/一致性
- 初步方案
- kv，hash，bucket
- 深入设计
- 基于优先级分级控制，冗余存储，同步/异步写，最终一致，hash同步，存储引擎
- 技术要点
- 柔性服务思维
- 故障尽量少影响到前端用户体验
- 识别关键路径
- 服务降级，设置合理超时防止雪崩
- 容灾预案，如仅50%流量可用时
- 负载均衡
- 代码级优化
- 运维层
- 监控
- 业务层
- 接口运行状态监控，数据库同步状态监控，自动化测试监控
- 系统层
- 业务层
- 监控
- 产品层
- 友好的故障提示
- 故障后的用户引导
- 前端友好等待策略
饿了么订单系统架构演进
- （微）服务架构演进
- 基于领域认知
- 松耦合、单一职责、关注分离
- 可验证的结果（系统能力效率的提升）
- 监控告警演进
- 重视业务指标（而非仅关注系统指标）
- Design for failure
- 补偿机制：消息补偿（MQ挂了暂时用内存Q补偿），流程补偿（用同步轮询补偿失败的异步请求）
- 随机故障测试（系统层，人为制造IO，CPU，网络压力，应用层，人为增加接口响应时间，对FailOver设计进行验证）